The present application is generally related to payment transactions, and more specifically to handling and/or authorizing payment requests by a consumer for a transaction.
Many Internet transactions are performed using credit, debit, or other type of account number. If an unauthorized person is able to obtain the account number or other information used in a transaction, the account may be compromised. The result may be unauthorized withdrawals or charges made by the unauthorized person. Most fraud occurs because of compromised merchants and acquirers who have received the account information during the transaction.
Although other systems attempt to prevent the merchant from obtaining the account number, such implementations require enrollment and extensive infrastructure changes. For example, in Google Checkout, a merchant must write new code to interface with a new entity, i.e. Google. Many additional requests and receiving of responses are added to the infrastructure of the merchant web site, e.g., via a plug-in. The merchant also needs to configure settings for the checkout, or monitor a merchant page in order to track an order. The merchant also has to cross-reference its order number with a unique identification number generated by Google. Also, the consumer needs to enroll with Google to obtain the benefit of the Google Checkout procedure. All of these and other steps require a lot of work by the merchant and consumer, and at a minimum frustrate the adoption of Google Checkout, along with the lack of other features.
Additionally, additional steps may be performed to protect a card that is compromised, stolen, or is being used without proper authorization of the cardholder. Prior methods attempt to authenticate the consumer in order to prevent security risks, such as fraud. However, such attempts have met with limited success. With the burgeoning growth of e-commerce and transactions conducted online, opportunities for payment card theft have become more readily available. As a result, online payment card fraud has also accordingly increased over the last few years. Despite many prevention efforts, payment card fraud continues to account for annual losses in the range of hundreds of millions of dollars. In addition to losses incurred due to payment card fraud, transactions lost due to false-positive declines (i.e., transactions that are incorrectly identified as fraudulent) also annually cost merchants and issuers hundreds of millions of dollars in sales.
Furthermore, existing industry solutions that combat payment card fraud tend to be account- and issuer-oriented. In other words, individual issuers may employ different solutions to detect fraudulent activities on their respective accounts and detection is at a single account level. As a result, payment card fraud that occurs across multiple accounts from multiple issuers often goes undetected. For example, it would be difficult for an individual issuer to determine that an usually high number of payment cards used at a particular merchant have been compromised and subject of fraud, since the fraud may only involve a small number of payment cards issued by that individual issuer.
Additionally, a limited time is typically allowed for an authorization to occur after a consumer has initiated the transaction, e.g., submitting a payment request via button on a web page. Thus, mechanisms that are used to authenticate the person, in order to prevent fraudulent activity, have very little time to run. Thus, only very simple mechanisms have been achieved thus far.
Better ways to perform electronic financial transactions and to authenticate consumers, particularly when the consumer is initiating a transaction over the Internet, are desirable. Embodiments of the invention address the above problems, and other problems, individually and collectively.